Thanks for the PR!

This seems reasonable on the surface, but probably indicates a bug further up the stack in your logging pipeline: loggers shouldn't construct events or invoke providers with the None level.

There's an ILogger.Error() method, for example, but no ILogger.None() method. How are these events being created in the first place?

That's the reason for the IsEnabled(LogLevel) method: to check which logger is enabled for the given level, before the event enters the provider.

It's correct that you don’t have a specific ILogger.None(), but there is the more general Log(ILogger, LogLevel, ...) commonly used when the level is dynamically determined during runtime.

That's the reason for the IsEnabled(LogLevel) method: to check which logger is enabled for the given level, before the event enters the provider.

I don't think that's necessarily the case. In the documentation you linked, note that the description for None begins with:

Not used for writing log messages.

This is different from "Used when a log message shouln't be written". The None value is a filter, it's not a valid level on events, and even code that calls ILogger.Log() dynamically should never call this method with the None value.

There's still possibly a bug somewhere, but it's likely to be in whatever is calling the IsEnabled() function. Happy to help track it down if you can send any further details.

Cheers!

For our case, it's Wolverine that's spam with log events with level None, as you can see, the log level is not determined at the point of time of logging.

Both the built-in console logger and Sentry have a check against None level in IsEnabled(), as seen here.

The only bug I can see is that the Seq provider does not discard None events. Are we on the same page?

Thanks for digging in deeper. Ugh, yes, I can see how this comes together :) ... awful, but I think you're right 👍

Published in 9.0.0 now - https://github.com/datalust/seq-extensions-logging/releases/tag/v9.0.0 - thanks @chrisbbe!